It is known in the field of databases that queries are optimized to execute efficiently. FIG. 1 shows a database management system (DBMS) 100. The DBMS 100 receives a query 102, and a query optimizer 104 outputs a query execution plan 106 that an execution engine 108 executes to perform the query 102. The optimizer 104 typically builds a query tree and optimizes the query tree while translating it into a tree of instructions (an execution plan) that are executable by the execution engine 108. How the optimizer 104 constructs the execution plan can depend on many factors, such as the query, the shape of the data in the database, sizes of the tables, data skew, the structure of the indexes, and so on. The optimizer 104 considers these factors, analyzes many possible plans, and picks the optimal one. While effective, runtime query optimization is limited to the current configuration of the database. That is, queries can execute only as quickly as design (e.g., indexes) of the database permits.
Another way to get queries to execute efficiently is to physically tune a database. That is to say, a database administrator (DBA) might physically tune a database by reconfiguring indexes, adding indexes, adding memory, and making other systemic physical changes that facilitate efficient execution of queries expected to be received by the DBMS.
To this end, physical design tuning tools have been used. FIG. 2 shows a physical design tuning tool 130. The tuning tool 130 is an application used by a DBA to explore alternate configurations of the database 102. Different storage boundaries 132 (e.g., memory limits) and physical configurations and workloads 134 (sets of queries) can be tested for performance results. The tuning tool 130 may function as a database client that communicates with the DBMS 102 through an interface (an API provided by the database) to submit “what-if” scenarios that the DBMS explores, tests, and provides feedback on without necessarily executing the queries. In other words, the DBMS 102 can give feedback on how well a query optimizes or performs according to a possible configuration. As a result, the tuning tool 130 may output some configuration 136 (e.g., some set of indexes I1 . . . Im) deemed to be ideal for the given boundaries 132 and workload 134. Generally, the tuning tool 130 may test many configurations for a query before deciding which configuration is optimal.
While physical design tuning is beneficial for improving database performance, it sometimes becomes expensive due to many what-if optimization calls. A tuning tool may examine many configurations, and in doing so perform many what-if calls to a database, possibly becoming a bottleneck for the tuning tool. Therefore, there is room to improve the actual performance of tuning tools that explore hypothetical configurations of a database.